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5 ATTRIBUTE TREE FOR MODELING VALUE OF MULTI-ATTRIBUTE 

PRODUCTS/SERVICES FOR AN ONLINE TRADING SYSTEM 



RELATED APPLICATION 

10 A provisional patent application entitled "System and Method of Modeling Value in an 
m Electronic Trading System" was filed on 4/17/00 by the same inventors for the present 
;S application, U.S. Provisional Appl. No. 60/198,125. 

P FIELD OF THE INVENTION 

|1| This invention relates to electronic commerce systems, and more particularly to value 
j=|5 and pricing of complex products. 

;| BACKGROUND OF THE INVENTION 

O The widespread adoption of the Internet has facilitated new relationships among buyers 
and sellers. Internet auctions and name-your-price services have empowered the 
consumer, offering deeper discounts with minimal consumer effort. More recently, 
20 business buyers have taken note of the price discounting on the Internet and have been 
seeking to cut costs through Internet-based purchasing. Business-to-Business (B2B) 
exchanges have sprung up in many markets to encourage competition among suppliers. 
Transaction costs are dramatically lowered since paper-based quotes and purchase 
orders are replaced by electronic documents. 
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While such electronic commerce exchanges are useful, often the products sold are 
complex. Many variations or configurations of a product can be sold. In the past, fixed 
prices were usually assigned to each configuration of a product or each product option, 
and a buyer merely had to add up the cost of the various options desired. However, 
5 these electronic exchanges often do not sell products based on a fixed price schedule. 
Complex pricing models may be based on volume purchased by a single buyer, or 
aggregation of demand by many buyers. The price may even be determined by auction, 
or by some other negotiation between the buyer and seller. The negotiations may even 
be carried out by computer programs that follow pre-programmed rules. 

10 

When complex pricing is combined with many possible configurations of a product, the 
complexity of any pricing models increases dramatically. When many buyers aggregate 
Jll demand, each of the buyers may prefer a different configuration of the base product, 
^ resulting in a confusing demand mix. Modeling such mixed demand is problematic. 

Bis 

k Q The various product configurations can be described using multiple product attributes. 

*/* Multi-attribute models are known in relational database and Online Analytical 

O Processing (OLAP) systems. Multi-attribute and multi-attribute electronic commerce 

11 ! 

m systems include multi-attribute auctions, negotiations, and contracts in electronic 
]3o procurement and other areas. 

In "Multi-attribute auctions for electronic procurement", by Bichler, Kaukal, & Segev 
(IAC ! s Workshop on Internet Based Negotiation Technologies, March 18-19, 1999 
Yorktown Heights, NY), the authors describe a system wherein price is one of the 
25 many attributes in determining the value of a product. Other attributes may optionally 
include shipping-handling costs, warranty etc. Here the value of a product is computed 
in terms of a utility function which is the weighted sum of the utility units 
corresponding to each attribute. 
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While such multi-attribute models are useful, a multi-attribute model more suited for 
electronic exchanges is desired. A way to express the many options or configurations of 
products in a product family is desired. It is desired to receive, store, and compare 
multiple product configurations from many buyers and sellers. A simple yet powerful 
5 structure to store many attributes of a product family is desired. 

SUMMARY OF THE INVENTION 

The present invention describes a system, method, and apparatus for participants in an 
electronic commerce application to model Value as a Complex Property. Value is 
modeled using the notion of Attributes. 

10 

i The system includes mechanisms for 

J 1. Naming Attributes 

l 

1 2. Defining Attribute metadata 

k 3. Giving Attributes Priorities 

f 5 4. Specifying and working with Dependencies Between Attributes 

5. Specifying and working with attribute ranges 

I 

I Further, the system includes facilities for 

J 1 . Representing Attributes 

20 2. Algorithms for Creating, Updating, and Looking up Attributes 

Attributes are represented using a dependency tree structure. Each attribute has a set of 
possible values. Each node in the tree represents an attribute and one of its possible 
values. The parent of such a node is a node that represents an attribute that this one is 
25 dependent on. For an attribute A with possible values vAl, vA2,.. vAk and an attribute 
B that is dependent on it with possible values vBl, vB2, ... vBl, each (A, vAi) node has 
1 child (B, vBj)j = 1...1. 
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The attribute tree for any trading partner can grow to be exponential. For instance, for 
a trading partner with N attributes, Al, A2, ... AN, and M values for each of the 
attributes, where some of these attributes are dependent on others, in the worst case is a 
trading partner tree with (M**N - 1)/(M-1). A system is provided that can, using 
5 heuristics, reduce this size to a manageable size. 

In general, a system is provided that allows a trading partner to breakdown and model a 
commodity in terms of a number of attributes and attribute values. In addition, the 
modeling system provides a facility to build an augmented products by adding new 
10 attributes or deleting existing attributes dynamically during the trade representing 
market conditions. 

g BRIEF DESCRIPTION OF THE DRAWINGS 

SI Figure 1 shows a trading partner (TP) attribute Tree. 

L- Figure 2 shows a path from the root to a leaf of an attribute tree. 

;ff 5 Figure 3 shows how the data from multiple data sources or applications can be obtained 

* implicitly. 

m Figure 4 is a block diagram of an attribute-tree builder. 

l ll Figure 5 shows one embodiment of a heuristic to create an attribute tree. 

p Figure 6 is a procedure for optimizing an attribute tree. 

20 Figure 7 is a flowchart for a Business-to-Consumer (B2C) application of the attribute 
trees. 

Figure 8 is a flowchart of an auction system enhanced by the attribute-structuring 
facility. 

Figure 9 is a flowchart of an optimal product/seller selector that helps a bidder. 
25 Figure 10 illustrates dynamic augmentation of a product with the attributes most desired 
by the potential buyers. 
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TERMINOLOGY 

1. Electronic Commerce - Commerce conducted over an electronic medium 

2. Electronic Exchange - A platform in which providers of goods or services buy, 
sell, and exchange those entities. 

5 3. Utility Function - defines a function used to define the value of a product. Typically 
this is price in some units like dollars or pounds that the buyer is willing to buy at 
or the seller is willing to sell at. 
4. Delta or Delta Value - A quantifiable vested interest of a trading partner. Different 
trading partners usually have different aspects of a trade that they value the most. 
10 Example: One might have price, the other may be concerned about quality, and the 

third might care about quantity and delivery time. The Delta is a manifestation of 
CJ their preferences and can be positive or negative; positive indicates that the trading 

i f 5 partner cares more about it and negative connotes the trading partner is less 

,^ interested in that particular attribute of a trade. 

R5 5. Product (Product and Service used interchangeably) 

6. Base Product Value or Base Value - is the utility function value (typically price) at 
;L which a trading partner starts valuing a product. 

Ul 7. Delta Product Value - is the utility function value (typically price) of the product 
j; with the deltas for the attributes accounted for 

;Sio 8. Trade - A trade is an activity in which one or more parties provide services or 
goods to one or more parties at a pre-calculated or at a dynamically decided or 
negotiated cost. 

9. Service category - Types of goods and services 

10. Trading Partner - A buyer / seller / facilitator in a multi-party trade. Also a service 
25 provider. 

11. Net Economic Value - Is the difference between the utility function value (typically 
price) at which a trading partner values a product and the utility function value 
(price) he actually trades at. 
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12. Attribute - An abstract data type that provides a mechanism for Trading Partners to 
describe their product/service to a finer level of granularity taking into account the 
strengths and weaknesses of the trading partners. Domain specific attributes will be 
defined by subclassing the base Attribute class. Ex: Date, Location, Weight are all 

5 attributes in the system 

13. Attribute Instance - An instance of a valid Attribute. Ex: Instance of a Date 
attribute. 

14. Attribute Value - Quantifiable values assigned to Attribute instances. Ex: )6/01/00 
assigned to a Date attribute 

10 15. Independent Attribute - Attribute with values whose delta is independent of any 
other attribute value 

16. Dependent Attribute - Attribute with values whose delta is dependent on another 
:|! attribute value 

if { 17. Attribute Range - Range over which an attribute's values are defined 
pis 18. Sets of Ranges - is a collection of disjoint ranges 

\ij 19. Attribute Interval - defines a segment between two contiguous attribute values in a 
T range 

•=? 20. Attribute Metadata - Properties of the attribute class (ranges, casting function, 
rtj creator, etc.) constitute the attribute metadata. 

So 21. Decision Master - The process or object that helps a trading partner decide on 

participation in one or more trades optionally based upon past trade performances 
and other business intelligence information. 

22. Attribute Value Tree - a dependency tree of attributes and their values for a product 
where any path from the root to a leaf represents a combination of attribute values 

25 chosen for the product. 

23. Attribute Value Delta Tree - an Attribute Value Tree which in addition to the 
attributes and values keeps DELTA values. Delta values may be kept at each node 
or cumulatively for the paths at each leaf node. 

24. TP Tree - A data structure containing the set of < attribute instance, attribute 

30 value > pairs and their respective Deltas of a Trading Partner. Though similar in 
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structure to a Trade Tree, a Trading Partner tree is typically a much larger set as it 
represents all services and their attributes that affect the final value of the service. 
25. Trade Tree - A data structure containing the set of < attribute instance, attribute 
value > pairs and their respective Deltas for a Trade. 

DETAILED DESCRIPTION 

The present invention relates to an improvement in e-commerce. The following 
description is presented to enable one of ordinary skill in the art to make and use the 
invention as provided in the context of a particular application and its requirements. 
Various modifications to the preferred embodiment will be apparent to those with skill 
in the art, and the general principles defined herein may be applied to other 
embodiments. Therefore, the present invention is not intended to be limited to the 
particular embodiments shown and described, but is to be accorded the widest scope 
consistent with the principles and novel features herein disclosed. 

The Decision Master (DM) is primarily responsible for making a decision on behalf of 
a Trading Partner (TP) in an Electronic Commerce System. The TP could be a 
participant in online shopping, auction, and electronic exchanges. The DM works with 
Attributes that model the notion of Value for the TP. 

An Attribute describes the value that a TP gives to a particular aspect of a product. For 
instance, a customer buying a travel ticket online may measure the value of that product 
as several attributes like time-of-departure, day-of-departure, month-of-departure, time- 
of-arrival, day-of-arrival, month-of-arrival, number-of-stops, airline, type-of-aircraft, 
type-of-seat etc. 

Each attribute has values defined over one or more ranges. For instance, number-of- 
stops may have a range of 0 to 3 with intervals of length 1. Thus, the range 0 to 3 has 3 
intervals 0-1, 1-2, 2-3. Attribute values are defined at the highest discrete point in a 
range which in this case is 1, 2, or 3. It is possible for attributes to have more than one 
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range. For instance, an airline that flies Monday- Wednesday, Friday-Saturday has 2 
ranges with 3 values in the first range and 2 in the second range. It can be assumed that 
in all intervals in any range are of fixed length. A non-fixed interval length range can 
be broken down into a collection of intervals with fixed length ranges. 

5 

Attributes may be dependent or independent. For instance, for each Day-Of-Week 
attribute value there are several Time-Of-Day attribute values. Here the Time-Of-Day 
attribute is dependent on the Day-Of-Week attribute. An attribute that does not depend 
on any other attribute is called an independent attribute. In this discussion one 
10 dependence tree structure is created by creating clever or arbitrary dependencies 
between attributes. 

d\ The Attribute data structure and the associated operators are shown in the attached code 
s £l of the provisional application. 

Kb 

if] The system also provides a mechanism to achieve differential pricing based upon 

attributes and their values. For each attribute value, a Delta is assigned which basically 
describes what the TP would pay if the product that the TP buys or sells includes this 
Rj attribute value. The Delta is simply described as a number that could translate to money 
S20 or any other quantifiable entity. For instance, a traveler may be willing to pay 50$ 
u more for an airline ticket that involves 0 stops or 50$ less for a ticket for each stop that 
the flight involves. 

Attributes may be Implicit or Explicit. Explicit Attributes are those that are explicitly 
25 described by the TP. Implicit Attributes are those that are implicitly discovered by the 
system based upon data obtained from information gathering or other business 
intelligence applications. 

It is assumed that Attributes may be managed, stored, and served by an Attribute 
30 Manager (AM) process or Server. For each attribute the AM contains information 
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about the name, ranges, and intervals of the attribute. Note that this AM is not 
dependent on any particular eCommerce or trading system that the TP is participating 
in. 

The inventors' system creates a TP Attribute tree (TP Tree) which encapsulates the 
dependency between all the attributes that the TP cares about for a particular product. It 
is described how the TP Tree is created and managed for a product. The Tree 
accommodates both dependent and independent attributes for implicit and explicit types 
of attributes. 

A collection of TP trees wherein within each tree the nodes are organized based upon 
dependency may be merged into a single TP tree. This may be required to enhance 
searching. 

Figure 1 shows a trading partner (TP) attribute Tree. The root 1 of the tree specifies the 
product that the TP is interested in trading. The base product 16 is an airline ticket 
from San Francisco to New York. The base value 14 is $300. Every node 2-10 of the 
tree represents an attribute name and value. Any path from the root of the tree to a leaf 
20 specifies a single product. This path is a path of attribute names and values. In the 
case of a tree with explicit attributes (where the client has explicitly specified the 
attributes and values) one could load the root of the tree with the "basic product 
value"(BPV) that the TP specifies for the product. The edges are labeled with delta- 
values 12 (+ or -) by which the TP modifies the product value when the subpath from 
the root 1 to the node at the end of the edge is chosen. For example, in figure 1, the 
Delta Product Value (DPV) from node 1-2 is +30, while the DPV from node 1-6 is the 
sum of DPVs from 1-2, 2-6 = +30 -30 = 0. The DPV at the leaf of the tree specifies 
the DPV along the entire path from the root to that leaf. 
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Figure 2 shows a path from the root to a leaf of an attribute tree. Attributes al to a6 are 
on a path to leaf 32 for tree 30. The value of the product at leaf 32 is the sum of the 
attribute values al, a2, a3...a6, plus the base value. 

IMPLICIT ATTRIBUTE TREES: 

5 As mentioned above implicit attributes are those whose delta product values (DPVs) are 
not explicitly available in the data. Consider the example of an online airline 
reservation system like Travelocity. One can find prices for air tickets from City A to 
City B for different airlines, different arrival, departure dates and times, for different 
classes of services and for different number of stops between the two cities. An 
10 automatic information gathering system can repeatedly query the Travelocity server and 

0 obtain this information and store this information in a store as in a relational database. 
J ti From the data stored in this store it can infer the attribute tree using complex sequel 

queries. 

|iJ5 Figure 3 shows how the data from multiple data sources or applications can be obtained 
^ implicitly. A data gathering system 34 and integration system 38 populate relational 

01 store 36. Notice that any other kind of store may be used to store the information. In 
"£ the example shown in figure 3, five pieces of data are stored for a particular airline in 
!f : store 36 - from city, to city, time of day, day of week, fare. Using this information the 

20 Implicit Attribute Tree is constructed as follows. Heuristics may be used to build this 
tree efficiently. The table may look like this: 



FROM 


TO 


TimeOfDay 


DayOfWeek 


Fare 


SFO 


NY 


Morning 


Monday 


240$ 


SFO 


NY 


Evening 


Monday 


200$ 


ORL 


SEA 


Morning 


Wednesday 


110$ 



The following steps may be followed in building the Attribute tree: 
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Step 1: The First values in the first two columns give the products. For instance, (SFO, 
NY) travel could be one product and (ORL, SEA) travel could be another product. 

Step 2: Then the names of the columns (Attribute Metadata, in general) are identified 
and checked with the AM. This helps figure out the ranges and the intervals for that 
attribute. For instance, name of column 3 "Time of Day" (or the data type of the data 
in column 3) is checked with the Attribute Manager to determine the ranges and the 
intervals for that attribute. 

Step 3: For each attribute whose range has m intervals a bit- vector of length m is 
created. For example, for DayOfWeek attribute a 7-bit vector is created with one bit for 
each day from Monday to Sunday. The I-th attribute value is represented by turning on 
the I-th bit in the bit vector. 

Step 4: The bit vectors are concatenated in the sense that if there are N attributes each 
with range of length m a bit vector of length N*m is created. This means that to 
represent and check all possible combinations of attribute values m**N possible bit 
vectors may be created. Each row in the relational table shown above creates a new bit 
vector. 

Figure 4 is a block diagram of an attribute-tree builder. Statistical system 48 reads 
relational data tables 40, 42, 44, which may be located on seller web sites. Online 
Analytical Processing (OLAP) system 46 may also be used to mine the data in relational 
tables 40, 42, 44 to determine delta values and attributes that determine the price of 
products in a product family. Systems 48, 46 then populate attribute trees 49. 

To avoid creating an exponentially large tree, heuristics may be used to create a sparse, 
but yet, reasonable representative of the tree. Standard statistical sampling techniques 
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may be used to do this. Figure 5 shows one embodiment of a heuristic to create an 
attribute tree. 

A table of fares (or values) is accessed, step 51. A parameter K is selected in step 52. K 
represents number of rows to select in steps 54 , 55. A base value is selected, step 53. 
For instance, it may be the lowest fare in the table or just an average of all the fares in 
the table. 

In step 54, K rows are selected from data store R that have the largest values. In step 
55, the K rows with the lowest values are selected. Thus 2*K rows are selected from 
the table (store R) where K rows represent the top K fares and the other K represent the 
bottom K fares. K is fixed a priori in step 52. 

The parameter P is selected, step 56. From the remaining rows, another P rows are 
randomly chosen based upon the values in columns corresponding to the leaf level 
nodes, step 57. 

From the remaining rows, for each subtree rooted at the node above the leaves, 
representative rows are sampled based upon the variance of the data at the leaf level, 
step 58. 

In step 59, the product values (DPVs) are computed for each path (each row picked 
from steps 54, 55, 57. The base product value must be carefully chosen in step 53. The 
tree is then re-balanced. 

Note that other heuristics may be applied to produce a representative sparse enough tree 
of the big attribute tree. When such a tree is looked up for an attribute value and/or a 
Delta associated with it, either it is found or it is missed. If the tree is a sparse 
representative of the actual tree, the missing element may be just not represented in the 
tree. The lookup algorithm should return a Delta that can be "guess"ed from the sibling 
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of the node where the looked up attribute value could have been. In order to be able to 
do this, one needs to optimize the implicit attribute tree. 

OPTIMIZING IMPLICIT ATTRIBUTE TREES - FIG. 6 

Figure 6 is a procedure for optimizing an attribute tree. Optimizing the attribute tree 
keeps high variance nodes on top and low variance nodes at the bottom. It is preferable 
for the sake of reduced representation of the attribute tree that the attributes whose 
values have low variance appear at the bottom of the tree and the attributes whose 
values show high variance be at the top of the tree. 

In order to do this the attributes are broken down into two types - Category types and 
Measure types. Measure types are those in which the values can be placed in a 
monotonic order. For instance, time-of-day, ages-of-people fall in this category. 
Category types include types like city-of-sale or shipping-company. Category types 
have values that are discrete in nature and there is no obvious monotonic ordering 
between attribute values. The choice of these types is somewhat arbitrary because while 
one can think of "city-of-sale" as a category type, one can look at the geographical 
location of the cities and identify a monotonic ordering based upon longitude or 
latitude. Category types can have hierarchies like city- > state- > country- > continent or 
day- > month- > quarter- > year. 

One could run column- wise queries to do the following: 

1. to identify the attributes that may be supported. 

2. To identify the distribution of the data over that attribute type (steps 62, 64). 

Once the distribution is identified, variance of the distribution can be identified, step 
66. Then attributes with low variance can be moved towards the bottom of the tree and 
the attributes with higher variances can be moved towards the root of the tree, step 68. 
This is done by comparing columns pair-wise to see which columns results in an 
attribute that is the parent of the attribute created by the other column. Given two 
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columns CI, and C2, let Al and A2 be the corresponding attribute types to be created. 
The node of type Al is a parent of the one of type A2 if the following is true: The 
average of the variances of the C2 values for each CI value is less than the average 
variance of the CI values for each C2 value, (low variance nodes lower). 

5 

In the case where there are too many values for a category type data with hierarchy, it 
may be hoisted to a higher level datatype to reduce the number of attribute values. For 
instance, if there are 1000 different occurrences of city-of-sale over 10 states one may 
choose to keep only state-of-sale information. For Measure type data one may combine 
10 close measures into measure ranges. For instance, instead of keeping age information 
by age a programmer may decide to keep this information by age groups. This allows 
building compact representations of the attribute trees. 

I EXPLICIT ATTRIBUTE TREES: 

l As mentioned before Explicit Attribute trees are created based upon explicitly provided 
J5 preferences of the TP. For instance, an air traveler might have the following decision 
logic: 

! 

I If flight on Monday - delta = +30 else if on Sunday delta = -30 else if on Tuesday 

} delta = +50 

1 

20 

If flight in Morning delta = +30 else if in the afternoon delta = +50 else if at night 
delta = -10 

25 From the logic given above an explicit tree may be created. It is preferable that the tree 
be sparse in nature for purposes of efficient processing. 
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CUSTOMIZING THE TRADING PARTNER TREE 

The Trading Partner Tree can be transformed into simpler representations when a TP 
participates in a trade. The Trade Tree is a restriction of the TP tree where the TP is 
participating in a trade of a particular product where some of the attributes and attribute 
5 values are not required or supported. 

USAGE OF THE ATTRIBUTE VALUE SYSTEM FOR INTELLIGENT E- 
COMMERCE APPLICATIONS 

The TP Tree, implicit or explicit, is used by a Trading Partner (end user or business) in 
participating in an electronic commerce application. For instance, the inventors' system 
10 allows an electronic business to attach true values to items based upon the attributes 
Q specified by the user. It allows the businesses to employ buyer-specific pricing of items 
m based upon the attributes specified by the buyer. It also allow businesses to target-sell 
^ items based upon user preferences. 

H|l 5 Figure 7 is a flowchart for a Business-to-Consumer (B2C) application of the attribute 
]L, trees. User visits a Vendor site to buy a product P, step 70. The user provides 

Wl specification for product P along with a list of attributes and values that he/she cares 

i y 

j~ about, step 72. 

20 The user specifies a baseline amount that he is willing to pay for the product, steps 74, 
76. (This is an optional block). 

The user may optionally specify how much he values each attributes, step 78. In one 
embodiment the user specifies "Delta" amounts for zero or more of the attribute and 
25 attribute values, steps 80, 82, 84. 

The vendor identifies and sells the product instance that the prospective buyer values 
the most (the one that computes to the maximum on the sum of the "Delta" values on 
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all the attributes; an alternative to the "Delta" amounts may be used like some other 
numeric scheme negotiated between the buyer and seller). This is shown in steps 86 , 
88, 89. 

5 The vendor could even dynamically place a true value on the product instance based 
upon the buyer attribute preferences. 

AUCTION SCENARIOS 

The attribute system enhances electronic auction systems where the bidder and the 
seller can price and/or determine the value of an auction item based upon multiple 
10 attributes of the item wherein the overall value of an item is determined by the value 

r| attached to individual attributes related to the item. In a forward auction system there is 

jt( a single seller and multiple prospective buyers. 

flu Figure 8 is a flowchart of an auction system enhanced by the attribute-structuring 
1^5 facility. Given a list of attributes associated with a product being auctioned, the method 
^ of figure 8 helps a prospective buyer to choose a bid based upon the attributes that 

yl he/she values the most. The seller puts up an item for auction with its attributes and 
]f\ attribute values, step 90. Each bidder has a baseline value for the item, and the 
y maximum bid prices is set to the baseline value, steps 92, 94. For each attribute that the 
20 bidder cares about, step 96, the bidder has a delta to be added/subtracted if the product 
includes/excludes that attribute, step 98. By going through all the attributes of the 
product (steps 95, 96) and adding/subtracting the deltas from the baseline value, the 
system computes the maximum bid price for the bidder, step 99. The bidder bids on the 
product between the baseline and the maximum bid price for what he/she thinks is the 
25 real value of the product. 

Figure 9 is a flowchart of an optimal product/seller selector that helps a bidder. In an 
auction system, where multiple products are being auctioned and each of the products 
have listed associated attributes, it enables the prospective buyer to bid on items that 
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satisfy most of his/her attributes. Here the bidder can pick between multiple sellers who 
are selling "similar" products but different support for attributes that the bidder cares 
about. The bidder looks for a product whose attributes have the most overlap with the 
attributes the bidder cares about and bids on that/those product(s). 

A bidder Bi looking for a product P finds several sellers auctioning the product in 
various configurations, steps 102, 104. For each seller, the seller's attribute tree is 
compared to the buyer's attribute tree, steps 108, 109. The attribute names, values, and 
ranges may not exactly match, so they may need to be normalized. The degree of 
overlap detected in step 110 is stored for that seller. The attribute tree comparison is 
repeated for the other sellers with the same buyer's attribute tree, steps 112, 106-110. 
The maximum overlap is found, step 114. The maximum overlap indicates an optimal 
product configuration by one of the sellers that most closely matches the desired 
configurations of the buyer. The buyer can then bid or purchase the product with the 
optimal configuration from the most-closely overlapping seller, step 116. 

A selling party may provide augmented products where the product being auctioned is 
dynamically augmented with new attributes to satisfy the attributes that are valued the 
most (or by most prospective buyers). Here the seller goes through all the attributes 
that bidders for a particular product care about and augments the product with those 
attributes and values that make it the most marketable item. 

Figure 10 illustrates dynamic augmentation of a product with the attributes most desired 
by the potential buyers. A matrix of attributes and possible attribute values is created 
for a product, step 130. Preference data is collected from several prospective buyers or 
bidders, step 132. For each potential buyer Bi, each attribute is checked to see if the 
user has entered a preference or attribute value for that attribute, step 138. When the 
buyer has entered an attribute value Vjt for attribute Aj, a counter for that attribute 
value is incremented, step 140. 
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An inner loop increments the loop variable j for all attributes, steps 142, 144. An outer 
loop increments the loop variable i, for all potential buyers, steps 146, 148. The loop 
variables are initialized in steps 134, 136. Thus all variables are checked for all 
potential buyers. The attribute counters incremented in step 140 are compared to find 
5 the maximum count(s), and the corresponding attributes are used to augment the 

product, step 150. The maximum counts corresponds to the most-desired attributes for 
the product. 

The above scenarios are only representative uses of the inventors' system in some 
10 auction systems. Many other scenarios and uses are contemplated. 

AGGREGATION 

id Aggregation is used in auctions to aggregate small buyers and sellers to match them up 
H| with a seller or a buyer who can only sell to or buy from large parties. Attributes can 
enhance the aggregation process by allowing aggregation of buyers and sellers not just 
:!| 5 based on products but based upon similarity in the attributes they value the most. 

\i\ Java interface classes and pseudo code were attached to the provisional application. 

O ADVANTAGES OF THE INVENTION 

The inventors' multi-attribute model is well-suited for electronic exchanges. The 
20 attribute trees provide a way to express the many options or configurations of products 
in a product family. The attribute tree is a convenient mechanism to receive, store, and 
compare multiple product configurations from many buyers and sellers. The attribute 
tree is a simple yet powerful structure for storing many attributes of a product family. 

25 The invention provides a system that allows a trading partner to model a product or 
augment a product with multiple attributes statically or dynamically based upon the 
other participants in the trade. The system discovers attributes from implicit set of data, 
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optimizes attribute representation when large number of attributes are present, and also 
allows dependencies between attribute values. The system can be used in a Business-to- 
consumer or Business-to-Business scenario. 

ALTERNATE EMBODIMENTS 

Several other embodiments are contemplated by the inventors. The increment of the 
counter can be by more than 1, or a negative increment (decrement) can be substituted. 
Non-binary counting schemes such as Gray Code can be substituted. Rather than 
incrementing the counter, the value that the buyer places on an attribute can be 
summed. Thus buyers who place more value on an attribute than other buyers can have 
a larger weighting for that attribute when the optimal set of attributes is determined. 

Attributes may also be discovered from the preferences of the trading partners. For 
example, a traveler may specify that he "prefers" flying in the morning and "detests" 
flying at night. These may be used to express time-of-day attributes with the value of 
"morning" with a positive delta of 20% of the base value of a ticket and the value of 
"night" with a negative delta of 50% of the base value. The attribute value of 
"afternoon" may have a delta of 0. 

The foregoing description of the embodiments of the invention has been presented for 
the purposes of illustration and description. It is not intended to be exhaustive or to 
limit the invention to the precise form disclosed. Many modifications and variations are 
possible in light of the above teaching. It is intended that the scope of the invention be 
limited not by this detailed description, but rather by the claims appended hereto. 
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We Claim: 

1 . A multi-attribute valuing system comprising: 

a buyer attribute-input for receiving a plurality of delta values for a product, each delta 
value indicating a higher or a lower true-value that the buyer places on the 
product when modified by the attribute associated with the delta value; 

a seller attribute-input for receiving a plurality of delta values for the product, each 

delta value indicating a higher or a lower true- value that the seller places on the 
product when modified by the attribute associated with the delta value; 

an attribute manager, receiving the attributes and delta values from the buyer and from 
the seller, for creating and managing attribute trees, each attribute tree 
specifying dependencies among the attributes of the product, the attributes 
associated with delta values that adjust a true-value of the product; 

an attribute-tree analyzer, receiving an attribute tree for the buyer and an attribute tree 
from the seller for the product, for comparing the delta values from the buyer 
with the delta values from the seller for a plurality of attributes that modify the 
product, the attribute-tree analyzer selecting an optimal specification of the 
product, the optimal specification including a series of the attributes; and 

a product specifier, coupled to the attribute-tree analyzer, for reporting to the seller the 
series of attributes for the optimal specification of the product, 

whereby the optimal specification of the product is determined by analyzing delta 

values specified by the buyer and the seller that adjust the true-value of the product. 

2. The multi-attribute valuing system of claim 1 wherein each branch of the 
attribute tree specifies an attribute, including an attribute name, an attribute 
value, and a delta value, 

whereby the attribute value specifies a value of the attribute that modifies the product 
itself, while the delta value specifies a true-value change offered to trade the product. 
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3. The multi-attribute valuing system of claim 2 wherein each branch of the 
attribute tree also specifies one or more ranges where each range has one or more 
interval of attribute values. 

4. The multi-attribute valuing system of claim 2 wherein each attribute tree 
includes a root, the root for specifying a base product unmodified by the 
attributes; 

wherein a path from the root to a leaf of the attribute tree specifies a final product, 
wherein the final product is the base product modified by attributes along the 
branches in the path from the root to the leaf, 

whereby the path through the attribute tree specifies attributes for the final product. 

5. The multi-attribute valuing system of claim 4 wherein the root of the attribute 
tree includes a baseline value, the baseline value being a value for the base 
product; 

wherein each node in each branch of the attribute tree includes the delta value, the delta 

value being a value adjustment for the product modified by the attribute 

specified by the branch; 
wherein a final true- value of the final product is generated by adding the baseline value 

to a sum of all delta values along a path in the attribute tree from the root to a 

leaf for the final product, 
whereby the final true-value is determined by summing the baseline value with the delta 
values along a path in the attribute tree. 

6. The multi-attribute valuing system of claim 2 wherein the product is an item for 
sale or a service. 

7. The multi-attribute valuing system of claim 2 wherein the attributes and the delta 
values are explicitly defined by the buyer or seller. 
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8. The multi-attribute valuing system of claim 2 wherein the attributes and delta 
value are implicit, the delta values being determined from other data. 

9. The multi-attribute valuing system of claim 8 further comprising: 

a data gatherer, coupled to a seller web site, for reading other data from the seller web 
site, the other data including price data for products with various attributes; 

a data store, coupled to the data gatherer, for storing the other data; 

an implicit tree builder, coupled to read the other data in the data store, for generating 
the attribute tree for the seller web site by comparing the price data in the other 
data for products with different attributes, 

whereby the attribute tree is generated implicitly. 

10. The multi-attribute valuing system of claim 9 wherein the data store includes 
records that contain a product specifier, attributes for the product, and a value for the 
product with the attributes stored in the record. 

11. The multi-attribute valuing system of claim 10 wherein the data store is a 
relational database. 

12. The multi-attribute valuing system of claim 9 further comprising: 

heuristic means for re-balancing the attribute tree generated by the implicit tree builder 

to produce a sparse representation of the attribute tree, 
whereby the attribute tree is re-balanced. 

13. The multi-attribute valuing system of claim 12 further comprising: 
optimizing means, coupled to the attribute tree, for re-arranging attributes in the 

attribute tree, wherein attributes with greater variances in attribute values are 
moved toward the root while attributes with lower variances are moved toward 
the leaf, 
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whereby high- variance attributes are moved near the root of the attribute tree during 
optimization. 

14. A computer-program product comprising: 

a computer-usable medium having computer-readable program code means embodied 
therein for indicating differential values of products in a product family, the 
computer-readable program code means in the computer-program product 
comprising: 

attribute means for storing product-attributes that specify products within the product 
family, the products varying according to product-attributes; 

input means for receiving delta values from a user, the delta values representing 

differences in values of products in the product family, the products varying 
according to the product-attributes, the delta values representing differences in 
value perceived by the user for the product specified by the product-attributes; 
and 

value attach means, coupled to the input means and to the attribute means, for attaching 

the delta values to the product-attributes to form a user attribute-store, 
whereby the user attribute-store indicates differences in values perceived by the user for 
products in the product family that vary in specification according to the product- 
attributes. 

15. The computer-program product of claim 14 wherein the product-attributes 
include dependencies wherein a value of one product-attribute depends on a 
value of a second product-attribute, the attribute means including dependency 
means for storing the dependencies of the product-attributes for the product 
family, 

whereby product-attribute dependencies are stored. 

16. The computer-program product of claim 15 wherein the user attribute-store 
comprises an attribute tree having a tree-like logical structure, the attribute tree 
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having a root that specifies a base product in the product family, the root 
branching into nodes according to the product-attributes, the final terminal 
nodes being leaves, the leaves each representing a product in the product family, 
whereby the user attribute store is an attribute tree. 

5 

17. The computer-program product of claim 16 wherein a differential value of a 

product is determined by summing delta values for each node along a path from 
the root to the leaf for the product, the final value of the product being the 
differential value added to a base value for the base product, 
10 whereby product values are determined by summing delta values along a path in the 
attribute tree. 

JJJ 18. The computer-program product of claim 14 wherein users include buyers and 
?f j sellers of a product in a product family; 

015 wherein a buyer is associated with a buyer attribute-store that is a user attribute-store 
in that stores the delta values perceived by the buyer; 

; y wherein a seller is associated with a seller attribute-store that is a user attribute-store 

O that stores the delta values perceived by the seller; 

}ij whereby buyer and seller delta values are stored by user attribute-stores. 

So 

^ 19. The computer-program product of claim 18 wherein the users also include 
facilitators and market makers, wherein trading partners include buyers, sellers, 
facilitators and market makers. 

25 20. The computer-program product of claim 18 wherein the computer-readable 
program code means further comprises: 
a value comparator, receiving the buyer attribute-store and the seller attribute-store, for 
comparing the delta values from the buyer attribute-store and the seller attribute- 
store for each product-attribute to find an optimal group of product-attributes 

30 that specify an optimal product for sale by the seller to the buyer, 
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whereby an optimal product in the product family for a sale is determined by comparing 
attribute stores of delta values for the buyer and for the seller. 

21 . The computer-program product of claim 20 wherein the buyer and seller are 
connected by a network; 

wherein the computer-readable program code means further comprises: 

network connection means for transmitting and receiving packets from remote clients 

for the buyer and the seller, 
whereby an electronic exchange connects the buyer and the seller. 

22. The computer-program product of claim 14 wherein the input means includes an 
explicit input to receive delta values from the user, 

whereby the delta values are directly input by the user. 

23. The computer-program product of claim 14 wherein the input means includes an 
implicit input that reads full-values for products in the family, the input means 
including compare means for determining the delta values for the product- 
attributes that specify the products in the product family, 

whereby the delta values are implicitly input from the user. 

24. The computer-program product of claim 23 wherein the input means includes 
scan means for scanning a product and value list to implicitly input the delta values. 

25. A computer-implemented method for selecting a product for sale to a trading 
partner comprising: 

receiving a selection of a base product from the trading partner; 
receiving a list of attributes for the base product from the trading partner; 
for each attribute in the list of attributes, receiving a delta value from the trading 
partner for the attribute, the delta value indicating an additional value the 



27 



trading partner places on the product when the base product is modified by the 

attribute, the delta values being trading partner-specified; 
selecting as a selected product the product modified by a subset of the attributes in the 

list of attributes, the subset of the attributes including attributes wherein a sum 

of the delta values for attributes in the subset of the attributes is a selected sum; 
offering the selected product to the trading partner for sale to the trading partner; 
whereby the product sold is selected using a selected sum of the delta values of the 
attributes specified by the trading partner. 

26. The computer-implemented method of claim 25 further comprising: 
receiving a baseline value from the trading partner, the baseline value indicating a value 

the trading partner places on the base product when not modified by any of the 
attributes; 

wherein the baseline value from the trading partner is an amount the trading partner is 
willing to pay for the base product, and the delta values are additional amounts 
the trading partner is willing to pay for the product modified by the attributes, 

whereby attributes of the selected product for sale to the trading partner are selected 

based on value specified by the trading partner for the attributes. 

27. The computer-implemented method of claim 26 further comprising: 
dynamically generating a true-value for the selected product based on the selected sum 

of the delta values and the baseline value, 
whereby a sales price is adjusted for trading partner-specified delta values of attributes 
for the selected product. 

28. The computer-implemented method of claim 25 further comprising: 
creating a trading partner attribute tree from the list of attributes and the delta values 

received from the trading partner, the attribute tree specifying values to the 
trading partner of the product modified by the attributes, 
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whereby the trading partner specifies values of the product modified by different 
attributes. 

29. The computer-implemented method of claim 28 further comprising: 
making a connection to the trading partner over the Internet. 

30. A computer-implemented tool for finding an optimally-specified product for 
purchase comprising: 

a buyer attribute-tree generator for generating a buyer attribute tree, the buyer attribute 
tree having a base product at a root of the buyer attribute tree, wherein each 
branch in the buyer attribute tree specifies an attribute that modifies the base 
product; 

base-product means for searching for sellers that are offering the base product for sale, 
the base-product means generating a sellers list of sellers that offer the base 
product for sale; 

a seller attribute-tree generator for generating a plurality of seller attribute trees, each 
of the seller attribute trees having the base product at a root of the seller 
attribute tree, wherein each branch in the seller attribute tree specifies an 
attribute that modifies the base product; 

an attribute tree comparator, receiving the buyer attribute tree and one of the seller 

attribute trees, for comparing the buyer attribute tree to the seller attribute tree 
and determining an overlap, the overlap indicating a degree of overlap of the 
attributes for the base product; 

wherein the attribute tree comparator compares seller attribute trees to the buyer 
attribute tree for all sellers in the sellers list; and 

an overlap maximizer, coupled to the attribute tree comparator, for finding a maximum 
overlap generated by the attribute tree comparator, the maximum overlap being 
generated for a maximum seller attribute tree of a chosen seller; 

wherein the chosen seller offers for sale the base product with attributes most-closely 
matching attributes specified by the buyer in the buyer attribute tree, 
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whereby the seller is chosen based on maximum attribute overlap by comparing 
attribute trees. 

31. The computer-implemented tool of claim 30 further comprising: 

a linker, responsive to the chosen seller from the overlap maximizer, for connecting the 
buyer with the chosen seller to allow the buyer to purchase the base product 
with the attributes most-closely matching buyer-specified attributes. 

32. The computer-implemented tool of claim 31 further comprising: 

a bid generator, coupled to the chosen seller, for sending a bid from the buyer to the 
chosen seller, the bid including a specification of the base product and the 
attributes that overlap the buyer attribute tree and the seller attribute tree for the 
chosen seller. 

33. A method for dynamically augmenting a product with attributes that are most 
valued by prospective buyers comprising: 

receiving a plurality of attributes and attribute values for the attributes from the 

prospective buyers; 
for each attribute, and for each prospective buyer, 

determining when a buyer has submitted an attribute value for the attribute; 

when a buyer has submitted the attribute value, adjusting a counter for the 
attribute value; 

examining the counter for each attribute value to find maximum attribute values, the 
maximum attribute values having the most prospective buyers submitting the 
attribute value to indicate buyer preference of the attribute with the attribute 
value; 

modifying the product according to the attributes with the maximum attribute values to 
form an augmented product that is more valued by the prospective buyers; and 
offering the augmented product for sale to the prospective buyers, 
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whereby the product is augmented with attributes preferred by most of the prospective 
buyers. 

34. The method of claim 33 wherein adjusting the counter for the attribute value 
comprises incrementing the counter for each prospective buyer that submitted 
the attribute value, 

whereby the counter is incremented for each prospective buyer submitting the attribute 
value for the attribute. 
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NH-1 

ATTRIBUTE TREE FOR MODELING VALUE OF MULTI- ATTRIBUTE 
PRODUCTS/SERVICES FOR AN ONLINE TRADING SYSTEM 

ABSTRACT OF THE DISCLOSURE 



An electronic commerce system facilitates trading of product families that contain 
individual products with varying attributes. The product's attributes specify products 
within the product family that vary according to these attributes. Delta values are 
received from a user. The delta values represent differences in values of products in the 
product family. These differences in value are perceived by the user for each of the 
products specified by the attributes. The delta values are attached to the attributes to 
form a user attribute tree. The root of the attribute tree is the base product, while the 
leaves of the attribute tree represent various configurations of the product. Summing 
delta values along a path from the root to a leaf provides the additional value of that 
product configuration. A buyer's attribute tree contains the buyer's perceived values for 
many different product configurations. The buyer's attribute tree can be compared to a 
seller's attribute tree. The overlap of the buyer's and seller's attribute trees can be used 
to d an optimal product configuration for sale to the buyer. 
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